1. Field of the Invention
The present invention relates to the field of computer systems, and more particularly, to a method and apparatus for allowing proprietary forwarding elements, such as special purpose networking hardware, to interoperate with standard control elements, generally implemented in software, in an open network architecture.
2. Background Information
In recent years, a trend has emerged in the networking hardware industry. Devices such as routers and switches have begun to evolve from monolithic, highly customized and integrated designs into aggregations of discrete, modularized components. The modularization of networking device architecture has begun to enable faster cycles of innovation and development in networking hardware and software by breaking the tight integration dependencies between the various components that make up a complex device, such as a router or switch. More recently, a further trend has emerged in the appearance of programmable ASICs (application-specific integrated circuits) or network processors. These devices allow for off-loading of application-layer or network-level packet processing from general purpose processors or servers to switches that include application-aware packet classification and processing capabilities. For example, a switch may not only perform routing lookup and forwarding in the hardware, but may also be able to perform functions of an application-level proxy and network or transport layer address translation. In order to take advantage of, and accelerate these trends, the use of a horizontal open networking architecture (see, for example, FIG. 2) seeks to standardize a set of APIs (application program interfaces) and protocols for separating the functionality typically associated with packet forwarding. Such functionality is usually implemented in special purpose hardware, which may be referred to as “forwarding elements”. The functionality associated with network signaling and control, typically implemented in software on general purpose processing architectures, may be referred to as “control elements”. The separation and standardization of networking device functionality, along with using control element and forwarding element components advocated by the horizontal open networking architecture, allows proprietary designs to continue to emerge while retaining the characteristics of openness, and further enabling innovation and rapid product development.
The separation of control and forwarding elements requires that a set of interfaces be developed for each component type. These interfaces expose the functionality of components to each other, allowing them to be integrated together in a working whole. For example, the functionality of application-aware switching capability in forwarding elements must be exposed to the control element via an open interface so that the control element can “program” the switch to off-load packet processing or forwarding functions in the data path. One way to expose such functionality is to define an abstract interface that describes switch capabilities in a generic manner. The control element can use such an abstract interface to configure or manipulate the switching functions using abstract commands/operations to achieve the desired effect, and the forwarding element must translate these abstract commands into hardware-specific tasks. The hardware-specific capability thus abstracted can cover a wide range of hardware capabilities, including ASIC-specific formatting of forwarding tables, packet queuing parameters, and per-packet processing actions such as encryption, marking, or address translation.
Exposure of the capabilities of the forwarding and control elements via interfaces has certain drawbacks. In particular, interface specifications typically reflect underlying implementations. This is generally true in the case of forwarding elements, which tend to be cost-sensitive, highly task-specific devices. In such devices, reflecting the underlying functionality in a highly abstract manner requires extra processing power (and thus cost) on the part of the forwarding element. The cost-sensitivity of these devices tends to discourage the use of abstract interfaces, instead leading to highly specific interfaces that closely match the actual implementation of each forwarding element. When building proprietary systems, where each component may be designed and built by the same manufacturer, this exposure is acceptable, because confidential information about the underlying implementation is kept within the company. However, when components from different vendors are integrated, particularly when using an open architecture, this exposure becomes problematic in that it can make visible information about the forwarding element architecture and capabilities that would not otherwise be available.